Internet Protocol Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same call or media session (multimedia session). By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The IP Multimedia Subsystem (IMS) network (also referred to as IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IPMM services over fixed and mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over Internet Protocol (IP)-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or multimedia sessions between user equipment and application servers. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the call or multimedia session. In addition to SIP, other protocols may be used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP).
A user equipment (UE) may comprise or represent any device used for communications over an IP-based communications network. Examples of UEs that may be used in certain embodiments of the described communication or access networks are fixed, wired or wireline devices, or mobile or wireless devices for accessing an IP based communication network, the devices may include, but are not limited to, computers, terminals, telephones, mobile handsets, mobile phones, smart phones, portable computing devices such as lap tops, handheld devices, tablets, net-books, computers, personal digital assistants, customer premises equipment, modems and other communication devices that may access an IP based communication network.
FIG. 1a illustrates schematically a communication network 100 in which a first UE 101 originates a call or multimedia session towards a second UE 103, the first UE 101 is located in an originating network 102 and the second UE 103 is located a terminating network 104. The first UE 101 and second UE 103 may communicate with each other through IMS network 105. The first UE 101 accesses the IMS network 105 via a first access network 106 within the originating network 102, and the second UE 103 accesses IMS network 105 via a second access network 107 within the terminating network 104. In addition, in the communication path between the first UE 101 and the IMS network 105 there is a first NAT device 108 in the originating network 102. Similarly, in the communication path between the second UE 103 and the IMS network 105 is a second NAT device 109 in the terminating network 104.
First and second NAT devices 108 and 109 allow a single public IP address to be shared between a number of UEs or IP hosts. UEs behind NAT devices (e.g. the first UE 101 is behind the first NAT device 108 and the second UE 103 is behind second NAT device 109) may be given IP addresses that are in a private IP address space allocated by a system administrator, an operator, or operators of first and second access networks 106 and 107. These private addresses may not be routable over a public IP-based network, for example, the Internet or another operator's access network, for example, over IMS network 105 and other communications networks. The first and second NAT devices 108 and 109 create temporary bindings between the public and private address space(s) on a per-connection basis. A binding is a mapping between the public address and port to a private address and port associated with a specific transport, for example, the user datagram protocol (UDP) or transmission control protocol (TCP).
The first and second access networks 106 and 107 may include any core network or access network technology including, but not limited to, various support entities or nodes (not shown) such as various interface nodes, access points, routers, LAN bridges, switches, base stations, switching centers, network gateways that provide an interface between the first and second access networks 106 and 107 and the IMS network 105. This will allow the first and second UEs 101 and 103 to communicate with each other through IMS network 105.
When a calling party such as user A of the first UE 101 originates a call or initiates a multimedia session to or with a called party such as user B of the second UE 103 the set-up process involves an originating call associated with the first UE 101 set up in the originating network 102 and a terminating call associated with the second UE 103 set up in the terminating network 104.
The terms “originating call” and “terminating call” may comprise or represent the session or connection set-up signalling in relation to the first UE 101 and the second UE 103, respectively. Examples of originating or terminating calls that may be used in certain embodiments of the described network, include but are not limited to, the connection set-up signalling enabling a communication connection to be made between user A of the first UE 101 and user B of the second UE 103 in the two call halves model. The originating call is the connection set-up signalling for user A of the first UE 101 in relation to the originating network 102 in the first call half and the terminating call is the connection set-up signalling for connecting the call with user B of second UE 103 in relation to terminating network 104 in the second call half.
The IMS network 105 includes an originating IMS 110 associated with the originating network 102 and a terminating IMS 111 associated with the terminating network 104. The originating and terminating IMS networks 110 and 111 may include network entities, nodes, or IMS network nodes that send/receive signals to/from the first and second access networks 106 and 107, respectively. These IMS network nodes connect with the first and second access networks 106 and 107 via the access network gateway or switching center nodes. The IMS network nodes may include Call/Session Control Function (CSCF) nodes, which operate as SIP proxies within the IMS network 105. The 3GPP architecture defines several types of CSCF nodes: the Proxy CSCF (P-CSCF) node which is typically the first point of contact within the IMS network 105 for UEs, which are SIP enabled; the Serving CSCF (S-CSCF) node provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) node whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a UE via P-CSCF node.
In this example, it is assumed that the first UE 101 is subscribed to IMS services, which include IMS voice services, messaging, video, multimedia etc. When the first UE 101 originates a call or multimedia session with the second UE 103, the first UE 101 will be the calling party and the call signalling of the first call half is the originating call in relation to the first UE 101. As the first UE 101 will use IP addressing, since this will be an IP-based call or multimedia session, the call set-up signalling will be directed from the first UE 101 via the first NAT 108 to the originating IMS network 110 in the originating network 102. As the second UE 103 is located in the terminating network 104, IMS network 110 sends the call set-up signalling to IMS network 111 for setting up the call signalling towards the called party, which is the second UE 103, and the call signalling of the second call half, i.e. the terminating call in relation to the second UE 103 is directed via the second NAT device 109 to second UE 103. The first and second UEs 101 and 103 will communicate through the IMS network 105 using SIP messaging to set up and control calls or multimedia sessions.
However, for SIP and SDP messages sent through the IMS network 105, the IP address located in the SIP Contact header and the SDP connection address (c-line) is usually identical because UEs will send SIP messages from the same IP address that they want to receive media at. Within the IMS network 105, SIP signalling and the multimedia session do not traverse the same network nodes as they are transported end-to-end independently of each other. The first and second NAT devices 108 and 109 will usually not be aware of the complex relations between the different signalling protocols and may not take these relations into account when performing IP address translation. This means SIP signalling, which the IMS network 105 uses for most call set-up signalling, may not be able to be used for UEs behind first and second NAT devices 108 or 109.
NAT traversal mechanisms allow a UE to find out whether it is behind a NAT device and to become aware of the public transport addresses (IP addresses and ports), such as public IP addresses and the public addresses of the remote end, which is the second UE in terminating network 104. The 3GPP Technical specification TS 24.229 specifies two NAT traversal mechanisms that will allow SIP signalling end-to-end for setting up multimedia sessions between UEs behind a NAT device using SIP. These are referred to as Interactive Connection Establishment (ICE) (or UE Managed NAT Traversal) and the Hosted NAT traversal (or Network Managed NAT Traversal).
FIGS. 1b and 1c are a schematic diagram and a signal flow diagram, respectively, illustrating an example of an ICE NAT traversal between the first UE 101 and the second UE 103 via originating and terminating networks 102 and 104. The first UE 101 and second UE 103 include a SIP port and a media port, the SIP port is used for SIP signaling represented by solid arrows, and the media port is the interface to the media bearers represented by dashed arrows for transporting traffic or media. It is assumed that the first and second UE 101 and 103 supports the ICE based NAT traversal.
Prior to initiating a multimedia session and setting up a multimedia stream, the first UE 101 interacts with a Traversal Using Relays around NAT (TURN) server 112a in the communication network 100 to discover a public transport address (IP address and port number) that the TURN server 112a may allocate to the first UE 101 such as IP address A3. The TURN server 112a provides relay functionality within communications network 100 so media can traverse first NAT device 108 via the TURN server 112a. The first UE 101 interacts with a Session Traversal Utilities NAT (STUN) server 113a to discover the public address, e.g. IP address A2, when first UE 101 is located behind first NAT device 108.
Given the transport address information from the TURN server 112a and/or STUN server 113a, the first UE 101 originates the call by sending towards the second UE 103, a SIP INVITE (call setup request) request message with an SDP offer including candidate address information based on the transport address information. The SIP INVITE request message traverses communication network 100 via an originating IMS-P-CSCF node 114a of the originating network 104 and terminating IMS-P-CSCF node 114b of terminating network 104.
In this example, the candidate address information includes three transport address candidates for the first UE 101, which are a relay transport address candidate for the first UE 101 (e.g. IP address A3 from TURN server 112a), a server reflexive address candidate for the first UE 101 (e.g. IP address A2 from STUN server 113a), and a local host address transport address candidate for the first UE 101 (e.g. IP address A). If only one of the endpoints (UEs) supports ICE, the TURN relay transport address will always be used (assuming there is a TURN server available in the network).
On receiving the SIP INVITE request message and the SDP offer from the first UE 101, the second UE 103 interacts with TURN and STUN servers 112b and 113b to gather candidate address information for the second UE 103 in the same manner as the first UE 101. The second UE 103 transmits towards the first UE 101, a SIP INVITE (call setup response) response message including an SDP answer (session description) including the candidate address information via terminating IMS-P-CSCF node 114b and the originating IMS-P-CSCF node 114a. The candidate address information for the second UE 103 includes three transport address candidates, which are a relay transport address candidate for the second UE 103 (e.g. IP address B3 from TURN server 112b), the server reflexive address candidate for the second UE 103 (e.g. IP address B2 from STUN server 113b), and the local host address candidate for the second UE 103 (e.g. IP address B).
After receiving the corresponding candidate address information from each other, the first and second UEs 101 and 103 perform the ICE procedure. In this procedure, the first and second UEs 101 and 103 send ICE connectivity checks to the transport address candidates received from the other UE 103 or 101 (endpoint). If only one endpoint is behind NAT device 108 or 109, or the involved NAT device(s) 108 and/or 109 are not address restrictive, then either the connectivity checks on the host address candidate(s) or the server reflexive address candidate(s) will succeed. This means TURN servers 112a and 112b are not required. In this case, the UEs 101 and 103 interact with TURN servers 112a and 112b to de-allocate the relay resources the TURN servers 112a and 112b tentatively previously reserved.
For ICE based NAT traversal, to not always result in using a TURN server 112a or 112b for relaying the traffic requires the first and second UEs 101 and 103 to support the ICE mechanism, or the IMS network 105 has to act as a back-to-back user agent (B2BUA) with regards to the ICE mechanism. However, there may also be many UEs that do not support ICE functionality such as legacy UEs and even some newer UEs. For NAT traversal to be possible for the UEs that do not support ICE and where NAT traversal is not solved on customer premises (through use of intelligent NAT devices such as Universal Plug and Play (UpNP) or SIP application layer gateway (ALG) based NAT traversal), IMS supports another NAT traversal mechanism called Hosted NAT traversal, which is relay based and similar to TURN server based NAT traversal.
FIGS. 1d and 1e are a schematic diagram and a signal flow diagram, respectively, illustrating an example of a Hosted NAT traversal mechanism between the first UE 101 and the second UE 103 via originating and terminating networks 102 and 104. The first and second UEs 101 and 103 include a SIP port and a media port, the SIP port is used for SIP signaling represented by solid arrows, and the media port is the interface to the media bearers etc represented by dashed arrows. It is assumed that the first and second UE 101 and 103 do not support the ICE based NAT traversal mechanism.
In the Hosted NAT traversal mechanism, the originating and terminating IMS P-CSCF nodes 114a and 114b perform NAT traversal by manipulating the transport address information in the media descriptions of the SDP offer and answer exchanged in the SIP signalling between the first and second UE 101 and 103. In doing so, the IMS P-CSCF nodes 114a and 114b place or insert IMS Access Gateway (IMS AGW) nodes 115a and 115b into the communication path between the first and second UEs 101 and 103 so that the media session is relayed via the IMS-AGW nodes 115a and 115b. 
Each of the IMS-AGW nodes 115a and 115b, will, if there is a NAT device 108 or 109 between it and the corresponding UE 101 or 103, do Hosted NAT traversal. This means the IMS-AGW node 115a and 115b discover the transport address (and port) used on the IMS side of the first and second NAT devices. This is performed by inspecting the source transport address information in the first packet received from each UE 101 and 103, respectively. This source transport address information is used as the destination transport address information for packets relayed in the other direction.
In this way, a multimedia session is set up between the first UE 101 and the second UE 103 such that the first and second NAT devices 108 and 109 are not required to manipulate the SIP signalling. However, this means that the communication path between the first and the second UEs 101 and 103 includes first and second NAT devices 108 and 109 and originating and terminating IMS-AGW nodes 115a and 115b. All of these devices and nodes need to perform address translation to allow multimedia session packets to be transmitted/received by the first and second UEs 101 and 103 resulting in increasing delays for multimedia packets traversing the communication path between the first and second UEs 101 and 103.
There are many reasons why the IMS P-CSCF nodes 114a and 114b may route multimedia sessions via an IMS-AGW nodes 115a and 115b. It may be due to a general security policy (e.g. authentication purposes), or required for mapping a specific multimedia session between IPv6 transport and IPv4 transport, or required for NAT traversal and at least one of the first and/or second UEs 101 and/or 103 does not support ICE, or for any other reason etc. However, if the first UE 101 and/or the second UE 103 uses ICE based NAT traversal and the IMS P-CSCF nodes 114a and 114b route the multimedia session via an IMS-AGW nodes 115a and 115b, then the ICE mechanism would result in choosing the relay candidate address (from TURN server 112a and/or 112b). This results in a TURN server 112a and/or 112b in series with IMS-AGW nodes 115a and/or 115b. This means the communications path between the first and second UEs 101 and 103 may include first and second NAT devices 108 and 109, TURN servers 112a and 112b, and IMS AGW nodes 115a and 115b, resulting in increasing delays for multimedia packets traversing the communication path between the first and second UEs 101 and 103.
This can be alleviated if the IMS P-CSCF nodes 114a and 114b can terminate the ICE signalling in the SIP signalling and SDP offer/answer bodies while the IMS-AGW nodes 115a and 115b terminates the ICE connectivity checks in the media plane. This is illustrated in FIG. 1f, which is a signalling flow diagram illustrating an example of a combined NAT traversal mechanism incorporating Hosted NAT traversal and ICE based NAT traversal. As specified in 3GPP TS 24.229, the IMS AGW nodes 115a and 115b can terminate the ICE signalling by replacing the ICE mechanisms address candidates in the SDP offer/answer bodies with host candidate addresses provided by the corresponding IMS AGW nodes 115a and 115b (e.g. IP addresses T1, T2, T3, or T4).
This means the communication network 100 will use Hosted NAT traversal and even if ICE mechanism is supported and used by the UEs 101 and 103, then the host candidate address will always be selected by the ICE mechanism, so there would never be both an IMS-AGW node and a TURN server in the established end-to-end media connection. However, this still means that the communication path between the first and the second UEs 101 and 103 will still include first and second NAT devices 108 and 109 and IMS-AGW nodes 115a and 115b, which need to perform address translation to allow multimedia session packets to be transmitted/received by the first and second UEs 101 and 103. This still results in delays for multimedia packets traversing the communication path between the first and second UEs 101 and 103 through first and second NAT devices 108 and 109 and IMS-AGW nodes 115a and 115b. 
An operator of an IMS network 105, or of originating IMS network 110, or of terminating IMS network 111 may need to deploy and manage TURN servers 112a and/or 112b and IMS-AGWs/Translation Gateway (TrGW) nodes 115a and/or 115b if their policy is not to always anchor media from first and/or second UEs 101 and/or 103 behind first and/or second NAT devices 108 and/or 109 via IMS-AGW nodes 115a and/or 115b, respectively. However, it is inevitable that current NAT traversal mechanisms can result increased or unnecessary delays for multimedia packets traversing the communication path between the first and second UEs 101 and 103. With the increasing use of high bandwidth multimedia applications, these delays will be unacceptable for time sensitive real-time multimedia traffic such as multimedia streaming, voice, and video conferencing applications.
There is a desire for a NAT traversal mechanism for use within an IMS network that minimises the number of nodes required for NAT traversal within the media communication path of a multimedia session.